>>>>> "Douglas" == Douglas Siebert <dsiebert@icaen.uiowa.edu> writes: Douglas> I'm curious exactly to see exactly how the various Douglas> vendors that have this vulnerability choose to fix it in Douglas> the long term. In the short term, patching telnetd seems Douglas> to be the solution. But what if the dynamic linker gets Douglas> a new variable in the future, and the people responsible Douglas> for that don't let the people responsible for telnetd Douglas> know? A better fix, IMHO, would be some sort of way to Douglas> compile some executables without support for altering Douglas> paths in this way. HP by default does not allow you to Douglas> modify the searching rules used for finding shared Douglas> libraries. But with a linker option, you can allow the Douglas> environment variable SHLIB_PATH to modify the searching Douglas> rules. Its a bit less flexible than, say, Sun or SGI, Douglas> but there are no worries about this sort of attack ever Douglas> being possible unless HP compiled system binaries with Douglas> this option, which they would of course be crazy to do. David Borman said he was working on an environment configuration file that would allow you to restrict some varibles, encode others so that you could run a short program (or build it into login) to decode them and add to the environment, and allow other variables like TERM through un-modified. I would probably apply such a solution to the Kerberos 5 telnetd when it becomes available; it sounds like a better approach than limiting user flexibility. Ideally, there should be a way to pass environment variables into login in some sort of sane way outside the environment and have login add them. I believe many sysv logins will allow you to specify environment variables on the command line. This might be worth experimenting with--perhaps we could convince the BSD folks to add this if it had useful security benefits. Douglas> -- Doug Siebert dsiebert@icaen.uiowa.edu